STraTOS 1997 April & May/STraTOS 1 - 1997 April & May.iso/CD01/INTERNET/SITES/RAND/ALL95.LZH/letters_fj/text0016.txt

Text File | 1995-10-04 | 10.4 KB | 250 lines

Hi,

> >Is that really 100% certain? We're after all only writing a program that
...
> I don't remember too well. Anyway, this has to be settled.

Yes, it can hardly hurt to contact iD in any case. I'd be very surprised
if they have any objections to us writing this program. After all it's not
based on any of their sources, it's unlikely to behave exactly the same and
it's for a computer they might not even know exists.

> Perhaps something like WAD, or BAD MOOD, I don't know. It's not very
                                 ^^^^^^^^
I like that one!

> important anyway.

No, but it'd be more comfortable to have at least a working title,
especially for discussions on newsgroups etc.

> >.WADs, though. The main memory hog seems to be the DVIEW temporary arrays
> >if my optimizations don't work.
> What do you mean?

The DVIEW rendering engine originally calculated all wall and floor segments
to be drawn before it started drawing anything. This made it necessary to
keep a couple of large arrays with coordinate information. I got rid of
most of that, but introduced some display glitches in the process.
See the old letters at the bottom for more info on this.

> >By the way, I wrote a couple of letters about this that I sent to Laurent
> >earlier. Would you like copies?
> Yes. Sure.

See at the end.

> >Well, it should be rather easy to extend DVIEW to handle texture mapping.
> I don't know. I would do it the other way round. That is, start from scratch
> a new program beginning with the rendering part. We would at first use very

In principle there's nothing wrong with that approach of course, but if
we're to get any kind of speed out of the engine we are likely to end up
with almost the same thing anyway IMO. We can't do the cheating that
everyone else is using with this kind of programs for the Falcon since our
datastructures and their behaviour is already defined.

> simple data that we would build by ourselves to test it. Then, extend this
> core, inspiring ourselves from DVIEW as much as possible.

I believe that kind of approach is very dangerous. The DVIEW engine for
example runs _much_ faster when the part of the map that's in front of you
is simple. Unfortunately, that's not very common in DOOM.

> It's IMO easier to do a good and machine specific program from scratch than
> try to optimize an already existent program. And it's C. Of course, it will
> save a lot of work and should be a constant inspiration and reference. What
> do you think?

Well, Laurent seems to think (see bottom) that optimizing DVIEW in assembly
will do wonders. I'm not that sure, though. Running the rendering on the
DSP is quite another matter, but then there's the problem of what to
transfer CPU<->DSP and how.

Before any real work is started I suggest that we profile the rendering
engine as far as possible. So far it seems to me that the biggest speedups
will be done at the highest levels (map clipping and projection).

> I'll try my ideas about texture mapping as soon as possible. I'll tell you
> about it when I have results. The problem is that I don't have much time to

I'm looking forward to hearing about it.

> program. And I have to admit that I work on another personal project, but

I still haven't made the general release of MGIF, but that's not taking much
time at the moment. Then there is another project that I've had not done
anything about for a couple of years and...

> that doesn't take me too much time, fortunately. Anyway, for me, Doom is the
> priority. After my job, of course.

Ah, yes there is that as well...

> BTW, I've never asked. What do you do in life, apart from programming?

I'm a doctoral student researching some new ideas in the field of VLSI
clocking and synchronization. The work also includes about 20% teaching,
so I don't expect to get my PhD before the next millenium (if I do indeed
continue that long and isn't kicked out).

In my free time (when I'm not programming) I read a lot (well, at least
it's 10-20kpages/year) of fiction, mostly thriller and fantasy. I also
play the trumpet in a big band and cornet in a brass band. I also took up
fencing recently.

What are you doing yourself? I recall your work/school had something to
do with physics.

Regards,
Johan

---- here follows some email I've exchanged with Laurent ----
I've incorporated some simple statistics collection in DVIEW which gave
some numbers that are interesting for the optimization. The figures are
approximate averages over more than 200 drawings from five different levels.

Function    Calls    Internal loops
                       (1)     (2)
Addfloor     150       1100
Addwall       50       1700
Coldraw      600
Rowdraw     1000
Drawnode     200
Drawssector  100        300
Loadseg      150       1600    400

Time for
structure setup:   0.28
actual drawing:    0.08
chunky to planar:  0.11

>From this data and some more examining of the code, I've come to the
conclusion that we'll never get anything close to adequate performance
running the 'structure setup' engine on the '030.
(I'd be glad to hear a different opinion.  ;-)
I am, however, almost certain that the necessary data from the .WAD can
be held in the DSPs RAM. The original 'structure engine' used a number
of large arrays, though, which would not have fit. Fortunately, I believe
I have found a way to get rid of almost all of that.

Finally, I've given some thought to the sprite drawing and discovered
that it will be even more tricky than I previously thought. The clipping
against walls and floors will be quite difficult. Perhaps even to such
a degree that the extra arrays I mentioned above must actually be
re-inserted, which would be very bad.
If you have any ideas on that I'd be glad to hear about them, since I'm
afraid it will be a major stumbling block for the project.

**********************************************

> I've started to look at the c source, it looks quite easy
> to translate in 68030. And, of course, in 68030, it'll run
> very FASTER ;-)  than in c, coz we can optimize assembler code,
> not c code... ;-)

I'd be surprised if we could get more than 2-3 times speedup on the
'030, but I'd very much like that suprise...  ;-)

> Before the sprites, I'd like to see the maze running fast and
> looking pretty good ...

Yes, the maze is of course the more important part, but I worry that
we'll optimize away the stuff that makes the sprites possible.
I'll stop thinking about that for the moment, though.

> I think it's not good to start coding details before we know
> how fast can go the essencial. From what you told me, you've
> managed to optimize the structure engine, but from how much ?
> I mean is it big ? ( I mean in memory, of course, to let it
> enter into the dsp).

The engine itself is not big at all as you can see from the sources.
I think the sources compile to around 5-10 kbyte m68k object code.
The data from the WAD I've used was also of quite reasonable size.

The problem is that the engine used a couple of arrays such as
intersections[50][320], walls[8000] and floorlist[200][40] each of
which must hold 16000 16 bit integers.
The arrays were used to store everything that needed to be drawn. The
actual drawing was then done when everything was ready.
My optimization consisted of drawing walls, floors and ceilings as
soon as they were available, which got rid of all three arrays mentioned,
but introduced a couple of new ones, which fortunately were quite small.
However, I realized yesterday evening that my optimizations will
sometimes produce incorrect displays. The original code drew all floors
before the walls, while I draw a wall(and the closest floor and ceiling)
at a time. In some cases, such as closed doors, there will be clashes...
I hope there's a way to handle this, but I've not discovered it yet.

I've heard that SNES DOOM has no floor or ceiling. I'll try that out.

> Actually, I'm looking at the c code, trying to understand the
> sequences order, to go faster after.

If you have any questions, feel free to ask me. I think I know what's
going on in most of the code now.

I guess you've seen that the author says that there must be a lot to
optimize in the actual 3D calculations.
Have you seen anything that can be done there?
Do you have any idea why he does the first clipping (to x = z)? If it's
removed, the most serious display glitches disappear...

> We'll probably have to reduce the size of the picture, to have a
> correct speed, the player could choose the size of the window...

I'll see how much that improves the speed.

> For the sprites, I've got many documents, I'll look what they say
> about it. If you want, I can send you a few documents. Bertrand sent

I'd be interested in that.

> Bye for now, tell me when you've got something new.

I'll try to send you a new version of DVIEW shortly. This will include
all my test stuff, which might be useful.

******************************************************

> I'm actually lookink at the code of dview_falcon. It doesn't seem to
> be so difficult to code in asm. I'll get a .WAD tonight by a PC friend.
> I'll test the programm, and tell you waht about it ...

So what did you think?

> What's new with you ?

I've spent far too much time with DVIEW, so I'm going to leave it as it is
for now. It simply refuses to do as I want...

Anyway, the sources are now ordinary C, compilable by GCC or TurboC/PureC.
They're quite ugly at the moment, since I've put quite a lot of debug and
test code in there.

If you press 'F' and 'W' while running, the program will switch to the
mode I think we have to use if we want to run it on the DSP.
Unfortunately I can't get rid of the errors that show up under some
circumstances in that mode. Floors sometimes show through doors and
disturbing glitches occur for some complicated structures.
For good examples of the bugs, go into the room directly on the left
in the first level and look at the top of the stairs. The problem there
is that the wall outside is drawn on top of rest of the room. The
secret door near the end of the level is an example of the 'transparancy'.
If you can fix those bugs, I'd be very happy.

By the way, I forgot to mention in the documentation that shows up when
you start the program that you can change the screen size using the
keys [ and ] for the width and { and } for the height.
DON'T try to increase the size above 320x200!


--
  Chalmers University   | Why are these |  e-mail:   [e-mail]
     of Technology      |  .signatures  |            [e-mail]
                        | so hard to do |  www/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)